Release 10.1A: OpenEdge Development:
Progress Dynamics Basic Development

Record locking and transaction scoping

Another significant feature of the Progress 4GL that loses much of its value in a distributed world is the whole area of record locks and transaction scoping. When your client application is looking only at data in temp-tables passed over from the server, you cannot hold record locks on the server while the user works with that data. You cannot easily scope a transaction from the client side that will update multiple records on the server in a single transaction. The whole way you think about and plan for data management changes somewhat because of this.

Data access in Progress Dynamics is always done based on “optimistic” locking. In a distributed application, you really have no other choice. Records are read NO-LOCK on the server, because you cannot hold record locks on the server as you pass the data to the client. In a stateless AppServer configuration, when the client session sends back an update, it will probably be executed in a different AppServer session anyway. So there is no built-in protection that someone else will not update the data while your user is looking at it. When an update comes back from the client, the server code that supports SDOs checks whether the data has been changed since you read it, and (unless you set a property indicating that you do not care) rejects the change.

In many cases, this might be satisfactory. Depending on the nature of the data, it is unlikely that two users will attempt to update the same record concurrently. Having an occasional update rejected, such that the user has to enter changes again, might be acceptable. Or with some data, it might not matter if two users change different parts of a record concurrently. In this case, you would set the CheckCurrentChanged property of the SDO to NO to indicate this.

But in other cases, you will want to maintain something like the record lock of a host-based or client/server application. To do this, you must build flag fields into your database that signal that a record or a set of related records is being updated, and write your application logic to observe this flag.